Machine-to-machine bootstrapping

ABSTRACT

Methods, devices, and systems allow for bootstrapping of a machine-to-machine device. In an embodiment, a bootstrap erase architecture allows the machine-to-machine server to manage bootstrap erase policies, detect access network specific events, initiate a bootstrap erase based on these policies and events, and allow for machine-to-machine server handover. In another embodiment, a device or gateway service capability layer may request its network service capability layer fetch data that the device or gateway, previously stored on a different network service capability layer. In another embodiment, when bootstrap erase is performed because the network service capability layer can no longer provide service to the device or gateway, the network service capability layer may recommend other NSCLs to the device or gateway. In another embodiment, a bootstrap erase procedure may be modified so that temporary identifiers may be assigned for a next bootstrapping event.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.14/888,977 filed Nov. 4, 2015 which is the National Stage Applicationfiled under 35 U.S.C. 371 of International Application No.PCT/US2014/036929, filed May 6, 2014, which claims the benefit of U.S.Provisional Patent Application No. 61/819,951, filed on May 6, 2013,entitled “M2M BOOTSTRAP ERASE PROCEDURES,” the contents of which arehereby incorporated by reference herein.

BACKGROUND

Bootstrapping is a process by which entities (e.g., an end-user deviceand server) perform mutual authentication and key agreement to establisha relationship enabling secure communications between them. Mutualauthentication is a procedure in which each party proves its identity tothe other. For example, if the Generic Bootstrapping Architecture (GBA)is used, authentication may be achieved by making a network componentchallenge the subscriber identity module (SIM) card of the end-userdevice and verify that the answer is identical to the one predicted by ahome location register (HLR) or home subscriber server (HSS).Authentication helps prevent a rogue device from registering with aserver by pretending it is a legitimate end-user device. Authenticationalso helps prevent a fraudulent server from performing aman-in-the-middle attack, which may consist of the fraudulent serverestablishing a connection with an end-user device by pretending that isa legitimate server.

Key agreement is a procedure in which the communicating entities derivea security key that they can then use to secure communications betweenthem, for example, by an encryption process that uses the security key.A feature of a key agreement mechanism is that the key is nottransmitted. The key derivation function may be based on a shared secretvalue that is meant for only an end-user device and server to know, forexample. This shared secret is also not transmitted. The key derivationfunction is designed such that it is prohibitively computationallycomplex for an eavesdropper, who does not know the shared secret, tocompute the key by observing the messages that are transmitted duringthe key agreement procedure. An overview of some authentication and keyagreement mechanisms is discussed herein.

Extensible Authentication Protocol (EAP) is not an authentication methodin itself, but rather a common authentication framework that can be usedto implement specific authentication methods. In other words, EAP is aprotocol that allows the Peer, Authenticator, and Authentication Serverto negotiate what authentication method will be used. The selectedauthentication method is then run inside of the EAP protocol. EAP isdefined in RFC 3748. RFC 3748 describes the EAP packet format,procedures, as well as basic functions such as negotiation of thedesired authentication mechanism.

EAP was designed as a link layer (Layer 2) protocol. Protocol forCarrying Authentication for Network Access (PANA) is a protocol that canbe used to carry EAP messages over an IP network. In other words, PANAis a transport for EAP. PANA runs on top of the network (IP) layer. PANAis defined in RFC5191. PANA allows dynamic service provider selection,supports various authentication methods, is suitable for roaming users,and is independent from the link layer mechanisms.

The SCL is a functional entity that may be implemented by hardwareand/or software and that provides functions exposed on reference points(i.e., functional interfaces between M2M entities). For example, the SCLmay provide common (service) functionalities that are shared or commonlyused by different M2M applications and/or services. These commonfunctionalities may be exposed using a set of open interfaces. Forexample, SCL may provide cellular core network functionalities through aset of exposed interfaces (e.g., existing interfaces specified by 3GPP,3GPP2, ETSI TISPAN, etc.) and may also interface to one or more othercore networks.

Bootstrap erase is a process in which entities break their relationship.Security keys are invalidated during bootstrap erase. If the entitiesattempt to communicate again after bootstrap erase, then thebootstrapping procedure is restarted. A machine-to-machine (M2M) server,a gateway, or device may initiate bootstrap erase. EuropeanTelecommunications Standards Institute (ETSI) M2M mId specification,ETSI TS 102 921, defines a bootstrap erase procedure. It is based on theprotocol for carrying authentication for network access (PANA)termination procedure, which is defined in RFC 5191. The procedureconsists of two messages passed between a device/gateway SCL (D/GSCL)and an M2M Server or NSCL. The first message requests a bootstrap eraseand the second message is a reply. Either the D/GSCL or the M2M servermay initiate the bootstrap erase process.

Bootstrapping is a process that often requires secret keys orcertificates provisioned in a device in order to achieve a desired levelof security. In a machine-to-machine environment, a large number ofdevices bootstrap with a M2M server.

SUMMARY

Disclosed herein are methods, devices, and systems related tobootstrapping. In an embodiment, a bootstrap erase architecture isdefined that allows a machine-to-machine (M2M) server to managebootstrap erase policies, detect access network specific events,initiate a bootstrap erase based on these policies and events, and allowfor M2M server handover.

In an embodiment, a network service capability layer (NSCL) handoverprocedure is defined where a device or gateway service capability layermay request its NSCL fetch data that the device or gateway previouslystored on a different NSCL. This procedure may allow the device orgateway to avoid recreating information on the new NSCL.

In an embodiment, when bootstrap erase is performed because the NSCL canno longer provide service to the device or gateway, the NSCL mayrecommend other NSCLs to the device or gateway. The recommended NSCL maybe better suited to serve the device or gateway.

Temporary identifiers may be used to hide the true identity of thedevice and device/gateway SCL (D/GSCL) when it attempts to re-bootstrap.In an embodiment, the bootstrap erase procedure is modified so thattemporary identifiers may be assigned for the next bootstrapping event.

This Summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used to limit the scope of the claimed subject matter. Furthermore,the claimed subject matter is not limited to limitations that solve anyor all disadvantages noted in any part of this disclosure.

BRIEF DESCRIPTION OF THE DRAWINGS

A more detailed understanding may be had from the following description,given by way of example in conjunction with the accompanying drawingswherein:

FIG. 1 illustrates an exemplary environment that service capabilitylayer handover may occur;

FIG. 2A illustrates an exemplary M2M system including devices andreference points;

FIG. 2B illustrates architecture elements for bootstrapping;

FIG. 3 illustrates event detection for bootstrap erase;

FIG. 4 illustrates service layer bootstrap erase and handover;

FIG. 5A is a system diagram of an example machine-to-machine (M2M) orInternet of Things (IoT) communication system in which one or moredisclosed embodiments may be implemented;

FIG. 5B is a system diagram of an example architecture that may be usedwithin the M2M/IoT communications system illustrated in FIG. 5A;

FIG. 5C is a system diagram of an example M2M/IoT terminal or gatewaydevice that may be used within the communications system illustrated inFIG. 5A; and

FIG. 5D is a block diagram of an example computing system in whichaspects of the communication system of FIG. 5A may be embodied.

DETAILED DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS

Embodiments set forth herein may be described in terms of arepresentational state transfer (REST) architecture, with components andentities described conforming to the constraints of a REST architecture(RESTful architecture). A RESTful architecture is described in terms ofthe constraints applied to components, entities, connectors, and dataelements used in the architecture rather than in terms of physicalcomponent implementation or communications protocols used. Thus, theroles and functions of the components, entities, connectors, and dataelements will be described. In a RESTful architecture, representationsof uniquely addressable resources are transferred between entities. TheETSI M2M specification (e.g., TS 102 921 and TS 102 690 as discussedherein) has standardized the resource structure that resides on an SCL.When handling resources in a RESTful architecture, there are basicmethods that may be applied to resources, such as Create (create childresources), Retrieve (read the content of the resource), Update (writethe content of the resource) or Delete (delete the resource.) Oneskilled in the art will recognize that implementations of the instantembodiments may vary while remaining within the scope of the presentdisclosure. One skilled in the art will also recognize that thedisclosed embodiments are not limited to implementations using the ETSIM2M architecture that is used herein to describe exemplary embodiments.The disclosed embodiments may be implemented in architectures andsystems, such as one M2M and other M2M systems and architectures.

Bootstrapping is a process that often requires secret keys orcertificates to be provisioned in a device in order to achieve a desiredlevel of security. In a machine-to-machine environment, a large numberof devices bootstrap with a machine-to-machine (M2M) Server. Addressedherein are bootstrapping related issues regarding sending deviceidentities “in the clear,” bootstrap erase events and policies, andservice capability layer handover, among other things.

Service capability layer (SCL) handover includes a process in which adevice or gateway that is registered to one NSCL may move itsregistration to a second NSCL and then initiate a procedure where thedevice or gateway's resources are transferred from the first NSCL to thesecond NSCL. Similarly, service capability layer (SCL) handover includesa process in which a device that is registered to one GSCL may move itsregistration to a second GSCL and then initiate a procedure where thedevice's resources are transferred from the first GSCL to the secondGSCL.

FIG. 1 illustrates an exemplary environment 100 in which SCL handovermay occur. NSCL 112 and NSCL 114 are connected with network 106. D/GSCL104, which is located within house 102, is communicatively connectedwith network 106 and other devices (not shown) in house 102. Car 101,which includes a machine-to-machine device, is communicatively connectedwith network 106. Environment 100 is divided into two areas separated byline 107—area 103 and area 105.

In an embodiment, referencing environment 100, NSCL 112 may provideservice A and service B. NSCL 114 may provide service A, service B, andservice C. D/GSCL 104 may initially be connected with NSCL 112 withregard to service A or service B. However, at some point in time, D/GSCL104 may need service C which is not provided by NSCL 112. When thisoccurs, D/GSCL 104 may be handed over to (registered with) NSCL 114 inorder to have service C provided. NSCL 114 may continue to provideservice C as well as service A and service B to D/GSCL 104 or be handedback to NSCL 112. Handover of D/GSCL 104 back to NSCL 112 may be basedon a variety of possibly weighted factors, such as frequency of use ofservices A, B, or C, latency, bandwidth, or the like.

In an embodiment, after D/GSCL 104 executes a bootstrap erase procedurewith NSCL 112, so that it may register with NSCL 114. Rather thanrecreating resources on NSCL 114, D/GSCL 104 may request that data, orresources, from NSCL 112 be transferred to NSCL 114. During thebootstrap erase process, D/GSCL 104 may be provided with a handovertoken that NSCL 114 can use with NSCL 112 to retrieve the D/GSCL 104related data from NSCL 112. A handover token may be a value, such as anumber, letter, or combination of numbers and letters, that, whenpresented, confirms authorization to access services or accessinformation. Here, NSCL 114 may provide NSCL 112 a handover token thatindicates NSCL 114 is authorized to retrieve D/GSCL 104 related datafrom NSCL 112. NSCL 112 may provide the handover token to D/GSCL 104.The handover token may be specific authorization for just D/GSCL 104related information or may be a more general authorization to accessother information (e.g., other D/GSCLs) on NSCL 112.

In another embodiment, referencing environment 100, car 101 may becommunicatively connected with NSCL 112. Bootstrap erase may be used bythe NSCL 112 to end its relationship with car 101 and recommend anotherNSCL, such as NSCL 114, that may provide services to D/GSCL 104. Afactor that may be considered in this process is that area 103 may begenerally allocated to NSCL 112 and area 105 may be allocated to NSCL114. When car 101 moves into area 105, the geographic area and otherfactors regarding the suitability of NSCL 112 to serve car 101, may beconsidered before handing over from NSCL 112 to NSCL 114.

FIG. 2A illustrates an exemplary ETSI M2M system 220 that may be used insome disclosed embodiments for machine-to-machine bootstrapping. Notethat this example system is simplified to facilitate description of thedisclosed subject matter and is not intended to limit the scope of thisdisclosure. Other devices, systems, and configurations may be used toimplement the embodiments disclosed herein, in addition to, or insteadof, a system such as system 220, and all such embodiments arecontemplated as within the scope of the present disclosure.

NSCL 226 may be in domain 222 and configured with network application(NA) 227 at M2M server platform 225. NA 227 and NSCL 226 may communicatevia reference point mIa 228. The mIa reference point may allow an NA toaccess the M2M service capabilities available from an NSCL in an M2Mdomain. In addition, within network domain 222 may be GSCL 241 andgateway application (GA) 242 that may be configured at M2M gatewaydevice 240. GSCL 241 and GA 242 may communicate using reference pointdIa 243. Further, within network domain 222 may be DSCL 246 and deviceapplication (DA) 247 that may be configured at M2M device 245. DSCL 246and DA 247 may communicate using reference point dIa 248. Each of GSCL241 and DSCL 246 may communicate with NSCL 226 using reference point mId224. In general, dIa reference points allow device and gatewayapplications to communicate with their respective local servicecapabilities (i.e., service capabilities available at a DSCL and a GSCL,respectively). The mId reference point allows an M2M SCL residing in anM2M Device (e.g., DSCL 246) or an M2M Gateway (e.g., GSCL 241) tocommunicate with the M2M service capabilities in the network domain andvice versa (e.g., NSCL 226).

NSCL 231 may be in domain 230 with NA 232. NA 232 and NSCL 231 maycommunicate via mIa reference point 233. There may be an NSCL 236 innetwork domain 235, and NSCL 239 in network domain 238. mIm referencepoint 223 may be an inter-domain reference point that allows M2M networknodes in different network domains, such as NSCL 226 in network domain222, NSCL 231 in network domain 230, NSCL 236 in network domain 235, orNSCL 239 in network domain 238, to communicate with one another. Forsimplicity herein, the term “M2M server” may be used to indicate aservice capability server (SCS), NSCL, application server, NA, or an MTCserver. In addition, the term user equipment (UE), as discussed herein,may apply to a GA, GSCL, DA, or DSCL. A UE, as discussed herein, may beconsidered a mobile station, a fixed or mobile subscriber unit, a pager,a cellular telephone, a personal digital assistant (PDA), a smartphone,a laptop, a netbook, a personal computer, a wireless sensor, consumerelectronics, medical devices, automobiles, and the like. M2M server or aUE may more generally be described as a machine-to-machine networkservices capabilities layer entity.

FIG. 2B illustrates functional architecture elements for bootstrappingin a machine-to-machine environment. In device or gateway domain 132there is a D/GSCL 134. D/GSCL 134 is communicatively connected to NSCL150 via interface link 136. Link 136 may be an mId interface asdiscussed in European Telecommunications Standards Institute (ETSI) M2MmId specification, ETSI TS 102 921. NSCL 150 may be communicativelyconnected with the devices, networks, and interfaces in block 137, suchas M2M authentication server (MAS) 138, M2M bootstrap service function(MSBF) 139, and core network 149.

M2M Bootstrap Policy Engine (MBPE) 142, machine type communicationinter-working function (MTC-IWF) 146, MTC-IWF 148, Tsp interface 144,and M2M Temporary Identifier Repository (MTIR) 140 may facilitate thebootstrapping process, such as initiating the bootstrap erase process.Tsp interface 144 may be the control plane as defined by 3GPP.Generally, an interface between an MTC-IWF and an M2M is called a Tsp.The MBPE 142 may be used to store, in a memory of the MBPE, policiesthat indicate when a bootstrap erase should be initiated with eachdevice. For example, MBPE 142 might hold a policy that indicates that abootstrap erase should be performed on a particular device if it ismoved into a new tracking area or geographic area. A processing functionof the MBPE may be configured to retrieve the policy from memory andcause the MBPE to act in accordance with the policy.

In greater detail, MBPE 142 is a logical entity that holds policiesregarding what events or conditions should cause particular devices, orgroups of devices, to be bootstrap-erased. When certain conditions, orevents, are detected, the MBPE policies may dictate that D/GSCL 134execute a bootstrap erase. For example, policies may indicate that abootstrap erase should be executed when a D/GSCL deregisters from theNSCL or because of a possible security threat, such as unexpectedmobility or change of international mobile subscriber identity (IMSI)and international mobile station equipment identity (IMEI) association.

Other conditions, or events, may indicate that NSCL 150 should no longerprovide service to D/GSCL 134. However, NSCL 150 may want to “handoff”D/GSCL 134 to another NSCL that may provide the desired services. Forexample, the current NSCL 150 might not be capable of serving devices ina given geographic area or may not have a relationship with the accessnetwork that is currently serving D/GSCL 134. It may be desirable tohandover D/GSCL 134 to another NSCL that may provide the desiredservices.

Table 1 lists exemplary types of network specific events that may causeNSCL 150 to initiate a bootstrap erase. In a 3GPP network, these eventnotifications are passed to MTC-IWF 146 (or MTC-IWF 148) by thedetecting node. For example, here, MTC-IWF 146 may notify NSCL 150 of anevent. In another example, a network node in the 3GPP core network A 149or core network B 147, such as a 3GPP Mobility Management Entity (MME),Serving General Packet Radio Service (GPRS) Support Node (SGSN), orMobile Switching Center (MSC) (not shown) may notify NSCL 150 when arouting area update, tracking area update, location area update, arouting area update rejection, tracking area update rejection, locationarea update rejection, or a change in serving node occurs for node 133that hosts D/GSCL 134. Node 133 may be a 3GPP UE. The SGSN, MME, or MSCmay not have a direct connection to NSCL 150. Notifications from theSGSN, MME, and MSC may be sent to NSCL 150 via MTC-IWF 146 and Tspinterface 144. In another example, in a 3GPP network an eNodeB (notshown) may inform NSCL 150 when node 133 that hosts D/GSCL 134 isexperiencing poor radio channel conditions. Notifications from theeNodeB may be sent to NSCL 150 via MTC-IWF 146 and Tsp interface 144. Inanother example, in a 3GPP network a Home Subscriber Server (HSS) (notshown) might inform NSCL 150 when node 133 that hosts D/GSCL 134 isexperiencing a change in IMSI/IMEI association. Notifications from theHSS may be sent to NSCL 150 via the MTC-IWF 146 and Tsp interface 144 orthey may be passed directly to NSCL 150 via other core networkinterfaces that are not shown in FIG. 2B such as a Mh interface.

TABLE 1 Access Network Events for Bootstrap-Erase Event Detecting NodeDescription Tracking/Routing/ mobility The device may have roamed intoan area Location Area Change management where service should not beprovided or where entity (MME)/ the device should be handed off toanother serving general NSCL. packet radio The following are exampleinterfaces that the service (GPRS) event notification may be passedover: support node T5a/b/c, Tsp (SGSN)/mobile switching center (MSC)Tracking/Routing/ MME/SGSN/ Routing area updates may be rejected if theLocation Area Change MSC device moves into a regional subscription zoneRejected identity (RSZI) that is not allowed. When this happens, itcould be an indication of device theft. The following are exampleinterfaces that the event notification may be passed over: T5a/b/c, TspChange of Serving MME/SGSN/ The new serving node may be owned by an NodeMSC operator that has no business agreement with the service provider.The new serving node might not support a T5 interface. The following areexample interfaces that the event notification may be passed over:T5a/b/c, Tsp Poor Channel Evolved node B Poor channel conditions couldbe used as an Conditions (eNodeB) indication that it would be moreefficient for the device to bootstrap erase and attempt to reconnect ata later time. The following are example interfaces that the eventnotification may be passed over: S1- MME, T5a/b/c, Tsp Change ofIMSI/IMEI HSS Change of IMSI/IMEI association could be an Associationindication of compromised security. The following are example interfacesthat the event notification may be passed over: S6m, Tsp, Mh

Machine type communication inter-working function (MTC-IWF) 146 andMTC-IWF 148 are network nodes that allow M2M servers (e.g., NSCL 150) tointerface to core network 147 and core network 149. MTC-IWF 146 andMTC-IWF 148 may hide the underlying topology of the core network fromNSCL 150. Here MTC-IWF 146 and MTC-IWF 148 are connected with NSCL 150via Tsp interface 144 and Tsp interface 145, respectively. Tsp interface144 and Tsp interface 145 may support trigger requests, among otherthings, from NSCL 150 to the core network.

NSCL 150 receives event information from the network, which may arrivevia Tsp 144 or Tsp 145. Based on the event information received, MSBF139 may make decisions on when devices should execute the bootstraperase procedure. Decisions may be based on the policies stored andprocessed in MBPE 142 and event information from an access network. TheM2M Temporary Identifier Repository (MTIR) 140 in FIG. 2B may be alogical entity that holds a database, or list, of temporary identifiersthat have been assigned to D/GSCLs (or other devices). MTIR 140 retainsthe mapping between the temporary identifiers and the permanentidentifiers. For example, a D/GSCL may have a temporary identifier ofqrxp3121994@lmnop.mfs. MTIR 140 may internally keep a mapping thatindicates thatqrxp3121994@lmnop.mfs=mikes-mobilehandset@mobile-network.com. MTIR 140may also retain the associated handover tokens, which is discussed inmore detail herein. A processing function of MTIR 140 may be configuredto retrieve the temporary identifiers or handover tokens from memory andcause the MTIR 140 to provide it to a computing device to makeappropriate decision or provide it to a display for viewing. The term“temporary identifier” may relate to an identifier that is used for apredetermined procedure or set of procedures (e.g., initialbootstrapping setup/registration), or for a predetermined time duration.After the procedure, set of procedures, or time duration, the temporaryidentifier may be exchanged for a new temporary identifier or apermanent identifier.

M2M device security includes challenges beyond the security challengesthat are inherent in most handheld devices. Unlike most handhelddevices, M2M devices are often deployed in areas where they are notalways visible to the owner. In other words, the physical security of anM2M device is more likely to be compromised than that of a handhelddevice. When events, such as mobility or a change of access network, aredetected by the NSCL, policies may require that a bootstrap eraseprocedure be executed with the D/GSCL. Events such as mobility, changeof access network, power cycle, loss of network coverage, and certaintypes of device tampering are sometimes detected by the access network,but not detected by the service layer. The access network's capabilitiesmay be leveraged to initiate bootstrap erase procedures. After executinga bootstrap erase procedure, the D/GSCL may re-execute the bootstrapprocess so that it can reauthenticate with the NSCL (or authenticatewith a new NSCL) and derive new security keys.

FIG. 3 illustrates exemplary flows of detected events that are passed toNSCL 166 to initiate bootstrap erase, which may occur during NSCLhandover or another event appropriate for executing bootstrap erase. Ina first scenario as shown in block 170, an event is detected by corenetwork (CN) node 162. Examples of core network nodes include networknodes like the nodes listed in Table 1, such as an MME, a HSS, or thelike. At 171, core network node 162 sends an event detectionnotification message to MTC-IWF 164. The event detection notificationmessage includes information notifying the NSCL 166 of an event, such asone of those listed in Table 1. At 172, MTC-IWF sends an event detectionanswer message to core network node 162. At 173, MTC-IWF forwards theevent detection notification to NSCL 166. At 174, NSCL 166 forwards anevent detection answer message to MTC-IWF 164. At 172 and at 174 themessages are acknowledgments that may use the diameter protocol. <At175, NSCL 166 sends an event policy check to MBPE 168. The event policycheck asks whether there are any policies governing these events, andthe event policy answer provides the policy. At 176, MBPE sends an eventpolicy answer message to NSCL 166. The event policy answer may indicateto NSCL 166 what action should be taken when the event occurs, based onthe stored policy with regard to bootstrapping maintained by the MBPE.For example, one such stored bootstrap policy may involve bootstraperase during a change of IMSI/IMEI association. The event policy answermay indicate that MBPE 168 policy is to ask the D/GSCL to bootstraperase when a change of IMSI/IMEI association occurs. At block 177, abootstrap erase decision is made based on the received informationregarding the event, which may include information returned in the eventpolicy answer. The policy helps determine the bootstrap erase decision.For example, if the policy states that it is okay for the D/GSCL to bemobile, when the network indicates a mobility event, NSCL 166 will notexecute a bootstrap erase.

FIG. 3 illustrates a second scenario shown in block 178. In thisinstance, the event is detected by an eNode B 160. At 179, eNode B 160sends an event notification message to core network node 162. Corenetwork node 162 begins the process with MTC-IWF 164 as similarlyillustrated in block 170.

FIG. 4 illustrates a flow 180 for bootstrapping as discussed herein. Insummary, in accordance with one embodiment of a novel bootstrappingprocess, NSCL 184 initiates a bootstrap erase and, as part of theprocess, recommends another NSCL (NSCL 186) to which D/GSCL 182 maysubsequently register. Once D/GSCL 182 registers with the recommendedNSCL 186, NSCL 184 and NSCL 186 execute a handover procedure. Thehandover procedure includes transferring the resources (i.e., data orinformation) regarding D/GSCL 182 that are stored on NSCL 184 to NSCL186. For example, the D/GSCL may have stored resources about itself onNSCL 184. The stored resources may include details of what services canbe provided by the D/GSCL, a history of sensor data that has beencollected by the D/GSCL, where the D/GSCL is located, etc. When theD/GSCL moves its registration from NSCL 184 to NSCL 186, thisinformation will be moved from NSCL 184 to NSCL 186.

At 191, D/GSCL 182 bootstraps and registers with NSCL 184. Afterword(e.g., based on a Bootstrap Erase Decision as shown in FIG. 3), at 192,NSCL 184 initiates a bootstrap erase procedure. In accordance with anembodiment of the novel process disclosed herein, the bootstrap eraseprocedure is initiated using a termination-request message. Generally,either the D/GSCL 182 or the NSCL 184 may initiate termination. In oneembodiment, the termination-request message may be similar to a protocolfor carrying authentication for network access(PANA)-termination-request as described, in RFC 5191. In accordance withthis embodiment, the termination-request message may further includeadditional value pairs (or the like) containing one or more of atemporary identification (tempSclId) value, a handover token(handOverToken), or a list of one or more recommended NSCLs, asdiscussed herein.

For example, when a NSCL is accessed by a D/GSCL over the publicInternet, there are times when the D/GSCL sends its D/GSCL identifier“in the clear” (e.g., without ciphering) when making an initial contactwith the NSCL. A preferable approach would be for the NSCL and D/GSCL touse an identifier that is temporary during the initial bootstrapping.The temporary identifier may be changed to a permanent identifier afterbootstrapping. It is preferable that the D/GSCL be provided withtemporary identifiers before executing a bootstrap erase. Thesetemporary identifiers may be used to hide the true identity of theD/GSCL when bootstrapping in the future with a particular NSCL that waspreviously (e.g., hours or days before) bootstrapped or another NSCLthat was appropriately (e.g., securely) informed of the temporary ID. Inone embodiment, the bootstrap erase procedure disclosed herein assignstemporary identifiers for the next bootstrapping event. This isillustrated in step 192 of FIG. 4.

As shown, at 192, D/GSCL 182 receives a temporary D/GSCL ID(tempSclId)—as part of the termination-request message—when NSCL 184initiates the bootstrap erase procedure. Because tempSclId is sentbefore termination of the connection, tempSclId is preferably encryptedwith an M2M root key, Kmr (or the like). The temporary D/GSCL ID may beused by the D/GSCL next time it attempts to bootstrap with an NSCL. Theprocess may be designed so that other NSCLs (e.g., NSCL 186) and otherservice providers will not resolve the temporary D/GSCL ID to theservice provider and/or NSCL (e.g., NSCL 184) who created theidentifier. NSCL 184 (or a service provider) who created the identifieris able to resolve the identifier to a permanent D/GSCL Identifier.

As also mentioned above, in one embodiment, the termination-requestmessage sent in step 192 may also include a handover token. Again,because the handover token is sent before termination of the connection,the handover token may be encrypted with Kmr (or the like). The D/GSCL182 may use the handover token the next time it connects with an NSCL,such as NSCL 186, for example. NSCL 186 may use the token to prove toNSCL 184 that D/GSCL 182 is registered with the new NSCL (NSCL 186) andshould be authorized to take ownership of the resources of D/GSCL 182.In an embodiment, the handover token may be provided in a“handOverToken” field of either the PANA-Termination-Request when theNSCL initiates the bootstrap erase procedure or in thePANA-Termination-Answer when the D/GSCL initiates the bootstrap eraseprocedure. The handover token is a unique key (a number, set of letters,alphanumeric, or the like) that the D/GSCL 182 can give to the new NSCL186. The new NSCL 186 can then use the token to prove to the old NSCL184 that the D/GSCL 182 has moved to NSCL 186. The token is anindication to NSCL 184 that it is safe to send any data that D/GSCL 182previously stored on NSCL 184 to NSCL 186

Further in accordance with the present embodiment, thetermination-request message sent in step 192 may include recommendedNSCLs with whom the D/GSCL 182 may connect as part of a hand-over. Therecommended NSCLs may be specified in the termination-request message inthe form of a list of NSCL (or MSBF) identifiers that the current NSCL(i.e., NSCL 184) recommends the D/GSCL 182 attempt to bootstrap. Therecommendation by NSCL 184 may be based on the services, among otherthings, used (or expected to be used) by D/GSCL 182.

Referring again to FIG. 4, at 193, D/GSCL 182 answers the request toperform the bootstrap erase procedure by sending a message to the NSCLrequesting that the bootstrap erase procedure be initiated (e.g.,termination request). In this case, the answer indicates if the D/GSCLaccepted the bootstrap erase request. At 194, D/GSCL 182 selects NSCL186 as the next NSCL with which it intends to bootstrap. This selectionmay be based on the list of recommended NSCLs provided in thetermination-request message received in step 192. At 195, D/GSCL 182sends a handover request message to NSCL 186. The handover requestmessage requests that the resources stored on NSCL 184, which arerelated to D/GSCL 182, be transferred to NSCL 186. In one embodiment,this request may be sent with a SCL update request indication(sclUpdateRequestIndication) message. The sclUpdateRequestIndicationmessage may provide the handover token (from the handOverToken field),as well as the identifier (e.g., NSCL-ID) of the old NSCL (e.g., NSCL184) to NSCL 186.

Table 2 provides additional details regarding the primitives of thesclUpdateRequestIndication message, in accordance with one embodiment ofthe novel bootstrapping methods discussed herein. The optional fields inTable 2, for example, may be used to request that the NSCL 186 fetch theresource tree of D/GSCL 182 from the NSCL 184 with which D/GSCL 182 waspreviously registered. In an embodiment, the D/GSCL may issue an SCLcreate request (sclCreateRequestIndication) before using thesclUpdateRequestIndication to perform the handover operation. ThesclCreateRequestIndication would happen right before step 195 in FIG. 4(not shown). Step 195 in FIG. 4 is the sclUpdateRequestIndication.Rather than including the fields in Table 2 as part of thesclUpdateRequestIndication message, an alternative approach may includethe fields in Table 2 in the sclCreateRequestIndication so that theD/GSCL registration and handover may be performed in a single step. Thehandover operation may not be done during the sclCreateRequestIndicationduring times when the sclCreateRequestIndication message may have beensent before the NSCL is authenticated by the D/GSCL. The handoverinformation may not be provided in the sclCreateRequestIndication if theNSCL and D/GSCL have not authenticated each other

TABLE 2 sclUpdateRequestIndication Description Primitive AttributerequestingEntity Application or SCL originally requesting the update ofan SCL resource targetID The uniform resource identifier (URI) of thetarget entity where the SCL resource is updated This request may address<sclBase>/scls/of the target SCL primitiveType SCL_UPDATE_REQUESTpreviousMsbf The MSBF identifier (MSBF-ID) of the last MSBF that theD/GSCL was bootstrapped with. This field is used when requesting thatinformation be handed over from an old NSCL or service provider to thenew NSCL or service provider. previousNscl The SCL identifier (SCL-ID)of the last NSCL that the D/GSCL was registered with. This field is usedwhen requesting that information be handed over from an old NSCL orservice provider to the new NSCL or service provider. previousSp Theservice provider identifier (M2M-SP-ID) of the last NSCL that the D/GSCLwas registered with. This field is used when requesting that informationbe handed over from an old NSCL or service provider to the new NSCL orservice provider. handOverToken When bootstrapping with a new NSCL, thistoken may be used by the new NSCL to retrieve the D/GSCL's resourcesfrom the old NSCL. Resource scl The resource representation of the sclto be updated

At 196, NSCL 186 sends a NSCL-NSCL handover request message to the NSCL184, requesting the data related to D/GSCL 182 that were stored on NSCL184. The NSCL-to-NSCL handover request message may include the handovertoken and the temporary D/GSCL 182 identifier. The handover token may beused to give a general authorization to access information from NSCL 184and the temporary D/GSCL 182 identifier may particularly inform NSCL 184which D/GSCL that NSCL 186 would like information about. In anembodiment, the NSCL-to-NSCL handover request message may be sentdirectly to the MSBF (not shown) that is associated with NSCL 184.

At 197, NSCL 184 responds to the NSCL-to-NSCL handover request messagewith the D/GSCL resources via a NSCL-to-NSCL handover answer message. At198, NSCL 186 will respond to the sclUpdateRequestIndication with a SCLupdate response confirmation message (sclUpdateResponseConfirm).

Disclosed are methods regarding how certain events may be detected bythe access network and used by the NSCL or like devices to initiate abootstrap erase procedure. A bootstrap architecture is defined in amanner that allows the NSCL to manage bootstrap erase policies, detectaccess network specific events, initiate a bootstrap erase based onthese policies and events, and allow for NSCL handover.

FIG. 5A is a diagram of an example machine-to machine (M2M) or Internetof Things (IoT) communication system 10 in which one or more disclosedembodiments may be implemented. Generally, M2M technologies providebuilding blocks for the IoT, and any M2M device, gateway or serviceplatform may be a component of the IoT as well as an IoT service layer,etc. With reference to FIG. 1 thru FIG. 4 above, the methods andarchitecture for bootstrapping disclosed herein may be implemented withthe M2M server and one more M2M devices (e.g., M2M gateway device or M2Mterminal device) shown in FIG. 5A through FIG. 5D. For example, M2Mgateway device 14 or M2M terminal device 18 of FIG. 5B may function thesame as D/GSCL 104 found in FIG. 1 and GSCL 241 or DSCL 245 in FIG. 2A.M2M service platform 22 of FIG. 5B may function the same as NSCL 112found in FIG. 1 or NSCL 231 found in FIG. 2A.

As shown in FIG. 5A, the M2M/IoT communication system 10 includes acommunication network 12. The communication network 12 may be a fixednetwork or a wireless network (e.g., WLAN, cellular, or the like) or anetwork of heterogeneous networks. For example, the communicationnetwork 12 may comprise of multiple access networks that providescontent such as voice, data, video, messaging, broadcast, or the like tomultiple users. For example, the communication network 12 may employ oneor more channel access methods, such as code division multiple access(CDMA), time division multiple access (TDMA), frequency divisionmultiple access (FDMA), orthogonal FDMA (OFDMA), single-carrier FDMA(SC-FDMA), and the like. Further, the communication network 12 maycomprise other networks such as a core network, the Internet, a sensornetwork, an industrial control network, a personal area network, a fusedpersonal network, a satellite network, a home network, or an enterprisenetwork for example.

As shown in FIG. 5A, the M2M/IoT communication system 10 may include anM2M gateway device 14, and M2M terminal devices 18. It will beappreciated that any number of M2M gateway devices 14 and M2M terminaldevices 18 may be included in the M2M/IoT communication system 10 asdesired. Each of the M2M gateway devices 14 and M2M terminal devices 18are configured to transmit and receive signals via the communicationnetwork 12 or direct radio link. The M2M gateway device 14 allowswireless M2M devices (e.g. cellular and non-cellular) as well as fixednetwork M2M devices (e.g. PLC) to communicate either through operatornetworks, such as the communication network 12 or direct radio link. Forexample, the M2M devices 18 may collect data and send the data, via thecommunication network 12 or direct radio link, to an M2M application 20or M2M devices 18. The M2M devices 18 may also receive data from the M2Mapplication 20 or an M2M device 18. Further, data and signals may besent to and received from the M2M application 20 via an M2M serviceplatform 22, as described below. M2M devices 18 and gateways 14 maycommunicate via various networks including, cellular, WLAN, WPAN (e.g.,Zigbee, 6LoWPAN, Bluetooth), direct radio link, and wireline forexample.

The illustrated M2M service platform 22 provides services for the M2Mapplication 20, M2M gateway devices 14, M2M terminal devices 18 and thecommunication network 12. It will be understood that the M2M serviceplatform 22 may communicate with any number of M2M applications, M2Mgateway devices 14, M2M terminal devices 18 and communication networks12 as desired. The M2M service platform 22 may be implemented by one ormore servers, computers, or the like. The M2M service platform 22provides services such as management and monitoring of M2M terminaldevices 18 and M2M gateway devices 14. The M2M service platform 22 mayalso collect data and convert the data such that it is compatible withdifferent types of M2M applications 20. The functions of the M2M serviceplatform 22 may be implemented in a variety of ways, for example as aweb server, in the cellular core network, in the cloud, etc.

Referring also to FIG. 5B, the M2M service platform typically implementsa service layer 26 that provides a core set of service deliverycapabilities that diverse applications and verticals can leverage. Theseservice capabilities enable M2M applications 20 to interact with devicesand perform functions such as data collection, data analysis, devicemanagement, security, billing, service/device discovery etc.Essentially, these service capabilities free the applications of theburden of implementing these functionalities, thus simplifyingapplication development and reducing cost and time to market. Theservice layer 26 also enables M2M applications 20 to communicate throughvarious networks 12 in connection with the services that the servicelayer 26 provides.

The M2M applications 20 may include applications in various industriessuch as, without limitation, transportation, health and wellness,connected home, energy management, asset tracking, and security andsurveillance. As mentioned above, the M2M service layer, running acrossthe devices, gateways, and other servers of the system, supportsfunctions such as, for example, data collection, device management,security, billing, location tracking/geofencing, device/servicediscovery, and legacy systems integration, and provides these functionsas services to the M2M applications 20.

FIG. 5C is a system diagram of an example M2M device 30, such as an M2Mterminal device 18 or an M2M gateway device 14 for example. As shown inFIG. 5C, the M2M device 30 may include a processor 32, a transceiver 34,a transmit/receive element 36, a speaker/microphone 38, a keypad 40, adisplay/touchpad/indicators 42, non-removable memory 44, removablememory 46, a power source 48, a global positioning system (GPS) chipset50, and other peripherals 52. It will be appreciated that the M2M device40 may include any sub-combination of the foregoing elements whileremaining consistent with an embodiment.

The processor 32 may be a general purpose processor, a special purposeprocessor, a conventional processor, a digital signal processor (DSP), aplurality of microprocessors, one or more microprocessors in associationwith a DSP core, a controller, a microcontroller, Application SpecificIntegrated Circuits (ASICs), Field Programmable Gate Array (FPGAs)circuits, any other type of integrated circuit (IC), a state machine,and the like. The processor 32 may perform signal coding, dataprocessing, power control, input/output processing, and/or any otherfunctionality that enables the M2M device 30 to operate in a wirelessenvironment. The processor 32 may be coupled to the transceiver 34,which may be coupled to the transmit/receive element 36. While FIG. 5Cdepicts the processor 32 and the transceiver 34 as separate components,it will be appreciated that the processor 32 and the transceiver 34 maybe integrated together in an electronic package or chip. The processor32 may perform application-layer programs (e.g., browsers) and/or radioaccess-layer (RAN) programs and/or communications. The processor 32 mayperform security operations such as authentication, security keyagreement, and/or cryptographic operations, such as at the access-layerand/or application layer for example.

The transmit/receive element 36 may be configured to transmit signalsto, or receive signals from, an M2M service platform 22. For example, inan embodiment, the transmit/receive element 36 may be an antennaconfigured to transmit and/or receive RF signals. The transmit/receiveelement 36 may support various networks and air interfaces, such asWLAN, WPAN, cellular, and the like. In an embodiment, thetransmit/receive element 36 may be an emitter/detector configured totransmit and/or receive IR, UV, or visible light signals, for example.In yet another embodiment, the transmit/receive element 36 may beconfigured to transmit and receive both RF and light signals. It will beappreciated that the transmit/receive element 36 may be configured totransmit and/or receive any combination of wireless or wired signals.

In addition, although the transmit/receive element 36 is depicted inFIG. 5C as a single element, the M2M device 30 may include any number oftransmit/receive elements 36. More specifically, the M2M device 30 mayemploy MIMO technology. Thus, in an embodiment, the M2M device 30 mayinclude two or more transmit/receive elements 36 (e.g., multipleantennas) for transmitting and receiving wireless signals.

The transceiver 34 may be configured to modulate the signals that are tobe transmitted by the transmit/receive element 36 and to demodulate thesignals that are received by the transmit/receive element 36. As notedabove, the M2M device 30 may have multi-mode capabilities. Thus, thetransceiver 34 may include multiple transceivers for enabling the M2Mdevice 30 to communicate via multiple RATs, such as UTRA and IEEE802.11, for example.

The processor 32 may access information from, and store data in, anytype of suitable memory, such as the non-removable memory 44 and/or theremovable memory 46. The non-removable memory 44 may includerandom-access memory (RAM), read-only memory (ROM), a hard disk, or anyother type of memory storage device. The removable memory 46 may includea subscriber identity module (SIM) card, a memory stick, a securedigital (SD) memory card, and the like. In other embodiments, theprocessor 32 may access information from, and store data in, memory thatis not physically located on the M2M device 30, such as on a server or ahome computer. The processor 32 may be configured to control lightingpatterns, images, or colors on the display or indicators 42 in responseto whether the NSCL-NSCL handover process in some of embodimentsdescribed herein is successful or unsuccessful, or otherwise showsinformation related to the NSCL-NSCL handover processes (e.g., theidentity of newly registered NSCL).

The processor 30 may receive power from the power source 48, and may beconfigured to distribute and/or control the power to the othercomponents in the M2M device 30. The power source 48 may be any suitabledevice for powering the M2M device 30. For example, the power source 48may include one or more dry cell batteries (e.g., nickel-cadmium (NiCd),nickel-zinc (NiZn), nickel metal hydride (NiMH), lithium-ion (Li-ion),etc.), solar cells, fuel cells, and the like.

The processor 32 may also be coupled to the GPS chipset 50, which isconfigured to provide location information (e.g., longitude andlatitude) regarding the current location of the M2M device 30. It willbe appreciated that the M2M device 30 may acquire location informationby way of any suitable location-determination method while remainingconsistent with an embodiment.

The processor 32 may further be coupled to other peripherals 52, whichmay include one or more software and/or hardware modules that provideadditional features, functionality and/or wired or wirelessconnectivity. For example, the peripherals 52 may include anaccelerometer, an e-compass, a satellite transceiver, a sensor, adigital camera (for photographs or video), a universal serial bus (USB)port, a vibration device, a television transceiver, a hands freeheadset, a Bluetooth® module, a frequency modulated (FM) radio unit, adigital music player, a media player, a video game player module, anInternet browser, and the like.

FIG. 5D is a block diagram of an exemplary computing system 90 on which,for example, the M2M service platform 22 of FIGS. 1A and 1B may beimplemented. Computing system 90 may comprise a computer or server andmay be controlled primarily by computer readable instructions, which maybe in the form of software, wherever, or by whatever means such softwareis stored or accessed. Such computer readable instructions may beexecuted within central processing unit (CPU) 91 to cause computingsystem 90 to do work. In many known workstations, servers, and personalcomputers, central processing unit 91 is implemented by a single-chipCPU called a microprocessor. In other machines, the central processingunit 91 may comprise multiple processors. Coprocessor 81 is an optionalprocessor, distinct from main CPU 91, that performs additional functionsor assists CPU 91.

In operation, CPU 91 fetches, decodes, and executes instructions, andtransfers information to and from other resources via the computer'smain data-transfer path, system bus 80. Such a system bus connects thecomponents in computing system 90 and defines the medium for dataexchange. System bus 80 typically includes data lines for sending data,address lines for sending addresses, and control lines for sendinginterrupts and for operating the system bus. An example of such a systembus 80 is the PCI (Peripheral Component Interconnect) bus.

Memory devices coupled to system bus 80 include random access memory(RAM) 82 and read only memory (ROM) 93. Such memories include circuitrythat allows information to be stored and retrieved. ROMs 93 generallycontain stored data that cannot easily be modified. Data stored in RAM82 can be read or changed by CPU 91 or other hardware devices. Access toRAM 82 and/or ROM 93 may be controlled by memory controller 92. Memorycontroller 92 may provide an address translation function thattranslates virtual addresses into physical addresses as instructions areexecuted. Memory controller 92 may also provide a memory protectionfunction that isolates processes within the system and isolates systemprocesses from user processes. Thus, a program running in a first modecan access only memory mapped by its own process virtual address space;it cannot access memory within another process's virtual address spaceunless memory sharing between the processes has been set up.

In addition, computing system 90 may contain peripherals controller 83responsible for communicating instructions from CPU 91 to peripherals,such as printer 94, keyboard 84, mouse 95, and disk drive 85.

Display 86, which is controlled by display controller 96, is used todisplay visual output generated by computing system 90. Such visualoutput may include text, graphics, animated graphics, and video. Display86 may be implemented with a CRT-based video display, an LCD-basedflat-panel display, gas plasma-based flat-panel display, or atouch-panel. Display controller 96 includes electronic componentsrequired to generate a video signal that is sent to display 86.

Further, computing system 90 may contain network adaptor 97 that may beused to connect computing system 90 to an external communicationsnetwork, such as network 12 of FIGS. 1A and 1B.

It is understood that any or all of the systems, methods and processesdescribed herein may be embodied in the form of computer executableinstructions (i.e., program code) stored on a computer-readable storagemedium which instructions, when executed by a machine, such as acomputer, server, M2M terminal device, M2M gateway device, or the like,perform and/or implement the systems, methods and processes describedherein. Specifically, any of the steps, operations or functionsdescribed above may be implemented in the form of such computerexecutable instructions. Computer readable storage media include bothvolatile and nonvolatile, removable and non-removable media implementedin any method or technology for storage of information, but suchcomputer readable storage media do not includes signals. Computerreadable storage media include, but are not limited to, RAM, ROM,EEPROM, flash memory or other memory technology, CDROM, digitalversatile disks (DVD) or other optical disk storage, magnetic cassettes,magnetic tape, magnetic disk storage or other magnetic storage devices,or any other physical medium which can be used to store the desiredinformation and which can be accessed by a computer.

In describing preferred embodiments of the subject matter of the presentdisclosure, as illustrated in the Figures, specific terminology isemployed for the sake of clarity. The claimed subject matter, however,is not intended to be limited to the specific terminology so selected,and it is understood that each specific element includes all technicalequivalents that operate in a similar manner to accomplish a similarpurpose.

This written description uses examples to disclose the invention,including the best mode, and also to enable any person skilled in theart to practice the invention, including making and using any devices orsystems and performing any incorporated methods. The patentable scope ofthe invention is defined by the claims, and may include other examplesthat occur to those skilled in the art. Such other examples are intendedto be within the scope of the claims if they have structural elementsthat do not differ from the literal language of the claims, or if theyinclude equivalent structural elements with insubstantial differencesfrom the literal languages of the claims.

What is claimed:
 1. A method for machine-to-machine (M2M) service layerhandover, the method comprising: registering a M2M device to a first M2Mservice layer entity, wherein registering comprises creating a servicelayer registration relationship between the M2M device and the first M2Mservice layer entity; requesting that the first M2M service layer entityfetch data associated with the M2M device from a second M2M servicelayer entity with information about a previous instance of service layerregistration with the M2M device, wherein the data is created by thesecond M2M service layer entity; and providing a handover token to thefirst M2M service layer entity, the handover token indicating that thefirst M2M service layer entity is authorized to retrieve the dataassociated with the M2M device from the second M2M service layer entity.2. The method of claim 1, further comprising receiving the handovertoken from the second M2M service layer entity.
 3. The method of claim1, wherein the requesting step is performed by the M2M device duringbootstrapping with the first M2M service layer entity.
 4. The method ofclaim 1, wherein the M2M device comprises a gateway service capabilitylayer or a device service capability layer.
 5. The method of claim 1,further comprising receiving, by the M2M device, a temporary identifierto identify the device during initiation of service layer registration.6. The method of claim 5, wherein the temporary identifier is receivedfrom the M2M second service layer entity before the M2M device isreleased from being bootstrapped with the second M2M service layerentity.
 7. The method of claim 5, wherein the temporary identifier isreceived from the M2M second service layer entity before the M2M deviceis deregistered from the second M2M service layer entity.
 8. The methodof claim 1, wherein the M2M device comprises a gateway application or adevice application.
 9. A machine-to-machine (M2M) device for M2M servicelayer handover, the M2M device comprising: a processor; and a memorycoupled with the processor, the memory comprising executableinstructions that when executed by the processor cause the processor toeffectuate operations comprising: registering a M2M device to a firstM2M service layer entity, wherein registering comprises creating aservice layer registration relationship between the M2M device and thefirst M2M service layer entity; requesting that the first M2M servicelayer entity fetch data associated with the M2M device from a second M2Mservice layer entity with information about a previous instance ofservice layer registration with the M2M device, wherein the data iscreated by the second M2M service layer entity; and providing a handovertoken to the first M2M service layer entity, the handover tokenindicating that the first M2M service layer entity is authorized toretrieve the data associated with the M2M device from the second M2Mservice layer entity.
 10. The device of claim 9, the operations furthercomprising receiving the handover token from the second M2M servicelayer entity.
 11. The device of claim 9, the operations furthercomprising receiving a temporary identifier to identify the deviceduring initiation of service layer registration.
 12. The device of claim9, wherein the requesting step is performed by the M2M device duringbootstrapping with the first M2M service layer entity.
 13. The device ofclaim 9, wherein the M2M device comprises a M2M device application. 14.The device of claim 9, wherein the M2M device comprises a device servicecapability layer.
 15. The device of claim 9, wherein the M2M devicecomprises a gateway application.
 16. The device of claim 15, wherein theM2M device comprises a gateway service capability layer.
 17. A computerreadable storage medium comprising computer executable instructions thatwhen executed by a computing device cause the computing device toperform the instructions comprising: registering a M2M device to a firstM2M service layer entity, wherein registering comprises creating aservice layer registration relationship between the M2M device and thefirst M2M service layer entity; requesting that the first M2M servicelayer entity fetch data associated with the M2M device from a second M2Mservice layer entity with information about a previous instance ofservice layer registration with the M2M device, wherein the data iscreated by the second M2M service layer entity; and providing a handovertoken to the first M2M service layer entity, the handover tokenindicating that the first M2M service layer entity is authorized toretrieve the data associated with the M2M device from the second M2Mservice layer entity.
 18. The computer readable storage medium of claim17, the operations further comprising receiving the handover token fromthe second M2M service layer entity.
 19. The computer readable storagemedium of claim 17, wherein the computing device comprises a deviceservice capability layer or a M2M device application.
 20. The computerreadable storage medium of claim 17, the operations further comprisingreceiving, by the computing device, a temporary identifier to identifythe computing device during initiation of registration.